[pull] master from supabase:master - #1123

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Content: adds a new blog post.

## What is the current behavior?

N/A

## What is the new behavior?

Adds the blog post announcing Sign in with ChatGPT (beta).

- Authors: Cemal Kılıç, Gregor Vand
- Categories: `product` · Tags: `auth`, `chatgpt`, `integrations`

## Additional context

Pre-flight checks (per CONTRIBUTING.md):
- [x] Prettier passes on the changed files
- [x] Vercel preview build succeeds for `www`

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
  * Added a blog post announcing the “Sign in with ChatGPT” beta.
* Documented signing in to Supabase with ChatGPT and connecting Supabase
through ChatGPT and Codex.
* Added guidance on consent, account onboarding, access revocation, and
getting started.
* **Chores**
* Updated an author’s displayed role from “Technical Program Manager” to
“Product.”

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

…ute (#48409)

Selecting "Last 7 days" on an Observability report rendered only the
most recent ~10 hours, while the header still showed the full range.

`timestamp_trunc` only does minute/hour/day, so
`analyticsIntervalToGranularity` floors any sub-hour interval to
`minute`. The `'30m'` and `'10m'` intervals used for 7-day and 24-hour
ranges therefore asked for 10,080 and 1,440 per-minute buckets. The
analytics endpoint caps each query at 1,000 data points, and report
queries are ordered newest-first with no `LIMIT`, so the oldest buckets
got dropped. Confirmed against a production HAR: 168h requested, exactly
1,000 rows returned, 10.6h of data.

Both tiers now use `'1h'` — 168 and 24 buckets respectively, well inside
the cap. Applies to Edge Functions, Auth and Realtime reports, which
share this helper.

Remaining sites that can exceed 1,000 points, not touched here:

- Logs event chart (`calcChartStart`) — minute buckets over a range
extended 6h earlier (~1,080), and hourly over a range extended 5 days
earlier (90d → 2,280)
- API and Storage reports (`PRESET_CONFIG`) and `SharedAPIReport` —
hardcoded `hour`, so a 90-day custom range is 2,160 points
- Query Insights — hardcoded `MINUTE` grouped per query, so unbounded

UnifiedLogs is fine; its ladder already caps at 720.

Fixes FE-4023

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Updated report date-range interval selection for ranges up to seven
days to use hourly granularity instead of 30-minute intervals for
clearer, more consistent reporting.

* **Tests**
* Added automated coverage for interval granularity across minute-,
hour-, and multi-week ranges.
* Included assertions validating expected hourly bucket counts for a
seven-day window.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Adds regression tests for something we noticed today. AI skills weren't
being loaded on https://supabase.com/docs/guides/ai-tools/ai-skills, so
while we fixed it, we wanted to make sure we could identify this faster.

## What is the current behavior?

Less tests. AI skills loading and not 

## What is the new behavior?

Two tests, no new workflows — both ride existing CI:

- **Unit test** (`AiSkills.utils.test.ts`) mocks GitHub, checks the
parsing/shaping logic (dir filtering, frontmatter, install command,
sorting, empty→fallback). Runs on every PR.
- **Smoke test** (`AiSkillsIndex.smoke.test.ts`) hits the live page and
asserts the skills table actually rendered. Runs in the daily docs smoke
job, and can be pointed at any environment via `DOCS_SMOKE_URL`.

Small supporting change: `getAiSkillsImpl` is now exported so the unit
test can call it directly.

## Additional Context

- Fixes
https://linear.app/supabase/issue/AI-915/skills-docs-page-fails-to-load-available-skills

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Tests**
* Added coverage for AI Skills loading, including directory filtering,
metadata parsing, install command generation, fallback descriptions, and
error handling.
* Added a smoke test confirming the AI Skills documentation page loads
successfully and displays install commands.
* **Refactor**
* Made AI Skills loading functionality accessible for direct testing
while preserving existing behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

)

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

- Updates the `description` copy of the `realtime-postgres-changes`
entry in `apps/www/data/features.tsx`
- Documents column selection as a key feature
- Clarifies that filters can be applied on one or more columns
- Removes a stale closing paragraph and normalizes the `Benefits`
heading

## What is the current behavior?

The Realtime Postgres Changes feature page lists five key features, does
not mention column selection, describes filtering without noting
multi-column support, and ends with a summary paragraph that is not part
of the approved feature copy.

## What is the new behavior?

- Key feature 3 reads "Granular filtering: Apply filters on one or more
columns to receive only relevant changes."
- New key feature 6 reads "Column selection: Opt in to receive only the
columns you choose in the event payload, with the primary key always
included."
- The `## Benefits:` heading is now `## Benefits`
- The closing paragraph "Supabase's Realtime Postgres Changes feature
provides a powerful tool for creating responsive, real-time applications
while leveraging the full capabilities of your Postgres database." is
removed

## Additional context

- The Realtime team shipped AND filter composition, expanded filter
operators, and column selection on 2026-07-02. Docs were updated on
2026-07-06.
- This change brings the feature page in line with the Notion Features
Page, which is the source of truth for feature page copy.
- Filipe Cabaço (Realtime) approved the content.
- `blogUrl` is intentionally not added in this PR. It will follow
separately once the launch blog post is live.
- Scope is limited to the `realtime-postgres-changes` entry. No other
feature entries were touched and the file was not reformatted. `prettier
--check` passes on the file.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Updated the “Realtime - Postgres changes” feature documentation with
clearer wording for granular filtering and row-level security
integration.
* Added a new bullet explaining column selection, including primary key
inclusion.
* Improved formatting in the benefits section and removed outdated
closing text.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Ana <ana1337x@users.noreply.github.com>

## Changes

Proxies `supabase.com/evals` to the
[evals](https://github.com/supabase/evals) frontend, following a similar
rewrite pattern as `/ui` and `/design-system`. The evals app already
serves under an `/evals` base path per supabase/evals#125.

The destination is hardcoded rather than an env var because the evals
app lives in a separate repo, and there’s not much benefit to a fully
local dev flow here, so the target URL is kept the same in every
environment.

## Before merge

- Disable deployment protection on the evals Vercel project, otherwise
`supabase.com/evals` will show a Vercel login page
- Wait until closer to Evals announcement target (July 30th)

Closes AI-826


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
  * Added routing for the `/evals` section and its subpages.
* Evals pages now load from the designated hosted destination while
preserving URL paths.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## Problem

The Docs E2E link checker found broken links throughout docs, starting
with `phone-login.mdx` pointing to `/docs/guides/cli/config` (404).

Old links like `/docs/guides/cli/config` still work on the live site
because `supabase.com` has redirects set up for them, but these links
break on the docs preview site, which is what the E2E check tests
against. These issues look clean on the live site, and I didn't catch
them in my first pass because I was testing production instead of the
preview.

The E2E check only tests the ~20 pages a given PR happens to touch, so
fixing the pages it flagged kept exposing more of the same problem one
page at a time as each fix pulled in a new file. To stop chasing this
incrementally, I cross-referenced every `/docs/guides/*` and
`/docs/reference/*` redirect source in `apps/www/lib/redirects.js`
against actual usage across all of `apps/docs`, and verified each
candidate against the live preview.

## Solution

Rather than updating the Docs E2E link checker, this PR resolves the
links. **Why:** we own these docs, so keeping the links clean without
redirects is keeping the house maintained. See [Broken Window
Theory](https://blog.codinghorror.com/the-broken-window-theory/).

Updated every link still using an old path to point straight at the
current page instead of relying on a redirect. This covers old links
like:

- `/docs/guides/cli/config` →
`/docs/guides/local-development/cli/config`
- `/docs/guides/cli/getting-started` →
`/docs/guides/local-development/cli/getting-started`
- `/docs/guides/cli/local-development` →
`/docs/guides/local-development/database-migrations`
- `/docs/guides/cli/managing-environments` →
`/docs/guides/deployment/managing-environments`
- `/docs/guides/cli/seeding-your-database` →
`/docs/guides/local-development/seeding-your-database`
- bare `/docs/guides/cli` → `/docs/guides/local-development`
- `/docs/guides/platform/compute-add-ons` →
`/docs/guides/platform/compute-and-disk`
- `/docs/guides/platform/shared-responsibility-model` →
`/docs/guides/deployment/shared-responsibility-model`
- `/docs/guides/database` → `/docs/guides/database/overview`
- `/docs/reference/javascript`, `/docs/reference/dart`,
`/docs/reference/kotlin`, `/docs/reference/python`,
`/docs/reference/csharp` → their `/introduction` pages (the redirect's
own destination, `/start`, turned out to be dead even on production — a
separate bug in `redirects.js` I didn't touch here)
- and about 35 more of the same pattern, listed in the commit messages

Also fixed a handful of dead heading anchors found along the way (links
that resolve to the right page but point at a `#section` that got
renamed or moved), including the original `#bigquery` anchor and a few
in `connecting-to-postgres.mdx` where content moved to its own dedicated
page.

Left alone on purpose:
- `content/guides/cli.mdx` — this page has no route in the docs app at
all (no `app/guides/cli/` directory), so it 404s even in production
before the `www` redirect ever fires. Fixing its internal link wouldn't
change that; it needs an actual routing/content decision, not a link
fix.
- A few candidates that already resolve fine as-is (`pg_partman`, bare
`/docs/reference/api`, bare `/docs/reference/cli`) — confirmed via curl,
left untouched.

## Manual testing

1. Confirmed every new link target actually exists by checking the
destination file/page and matching heading anchors.
2. Cross-referenced every `/docs/guides/*` and `/docs/reference/*`
redirect source in `apps/www/lib/redirects.js` against real usage in
`apps/docs`, and curl-verified each old path (404) and new path (200)
against the live PR preview before fixing it.
3. Ran the Docs E2E link checker locally against changed pages.
4. Spot-checked the original broken link from CI
(`/docs/guides/cli/config`) to confirm it now points to a working page.